mnf: 





PATENT 




IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



Applicant 



Nouri, et al. 



Group Art Unit 2758 



Appl. No. 



08/942,333 



Filed 



October 1, 1997 



For 



SYSTEM FOR RESETTING A 
SERVER 



Examiner 



Philip Tran 



DECLARATION UNDER 37 C.F.R. § 131 TO OVERCOME JOHNSON 

1 . This declaration is to establish the status of the invention in the above-captioned U.S. patent 
application in the United States on August 16, 1996, which is the effective date of U.S. Patent No. 
5,857,074, entitled "Server Controller Responsive to Various Communication Protocols for 
Allowing Remote Communication to a Host Computer Connected Thereto", to Johnson, which was 
cited by the Examiner against the above-captioned application. 

2. We are the named joint inventors of the described subject matter and all claims in the 
above-referenced application. 

3. We have re^d the Office Action mailed January 26, 1999 (Paper No, 7) regarding the 
above-captioned application. 

4. We developed our invention as described and claimed in the subject application in this 
country, as evidenced by the following events: 

a. By at least November 1995, 1, Karl Johnson, had conceived of a control diagnostic 
and monitor subsystem for a server system. A document, entitled "Raptor System: A 
Bird's Eye View, Version 0.99", was written at least as early as November 2, 1995, as 
evidenced by the document date. A copy of the cover page, and pages 8 and 9 of 
document is attached as Exhibit A. The control diagnostic and monitor subsystem was 
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to control various system aspects, including system reset, without the use of physical 
switches. 

b. By at least January 1996, I, Karl Johnson, had conceived of using a network of 
microcontrollers as the monitoring and control hardware of the subject invention. A 
document, entitled "Raptor Wire Service Architecture, Version 1.0" ("Wire Architecture"), 
was written at least as early as January 23, 1996, as evidenced by the document date. A 
copy of the cover page, pages 2-4, 7-8 and 20-25 of Wire Architecture is attached as 
Exhibit B. Page 2 describes a generic Wire Service message format utilized by the 
invention. Pages 3-4 describes a bit data type, a byte data type, and a string data type used 
for data transfer, while pages 7-8 describe an event data type for alerting extemal interfaces 
(such as the remote interface) of events in the Wire Service (microcontroller network). 
Wire Architecture also discloses a Wire Service Network Memory Map of all Wire Service 
(microcontroller network) addressable entities at pages 20-25 of the document. For 
example, page 22 of the Wire Architecture indicates several of the addressable entities 
associated with the server (an example of a first computer) power supplies. These entities 
include an analog measure of the voltage for the main power supplies and a power supply 
DC OK status which could be monitored by the Remote Interface microcontroller and/or 
passed on to the Recovery Manager at the client (an example of a second computer). These 
and other entities described at pages 22-23 may be utilized by the system reset operation. 

c. The server power operations were documented in a specification entitled "Raptor 
Theory of Power On Operation, Version 1.0" ("Power Operation") , written at least as early 
as March 1, 1996, as evidenced by the document date. Wei Wu, employed by our employer 
NetFRAME Inc., prepared this document based upon information provided by me, Karl 
Johnson. A copy of the cover and pages 1-5 of Power Operation is attached as Exhibit C. 
Page 1 shows a block diagram of the relationship between Wire Service, the System 
hardware, the BIOS, the Operation system, and the Application. Page 1 also describes that 
Wire Service resets the system, and discusses BIOS operations, including cold start and 
warm start. 

d. By at least April 1996, I, Karl Johnson had conceived of an architecture for the 
remote interface module. The remote interface module may be incorporated in or on the 
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server enclosure. The remote interface communicates with the server microcontroller 
network and with external computers via a RS-232 port, for example. The remote interface 
also provides remote power jfrom a remote interface power supply that is mdependent of the 
server power supply. A schematic, entitled "Schematic of Raptor Remote Board, Revision 
01", was drawn at least as early as April 1, 1996, as evidenced by the document date. A 
copy of sheets 1 of 2 and 2 of 2 of the schematic is attached as Exhibit D. A remote 
interface microcontroller (PIC16C65), memory and RS-232 interface are shown on sheet 1. 
The top left portion of sheet 2 generates the independent power. The independent remote 
interface power supply is not shown but connects to connector J2 on pins 1 and 2. A RJ45 
connector PI (also on sheet 2) provides an interconnection point between the remote 
interface microcontroller and the server microcontroller network. 

e. The architecture for the remote interface was documented in a specification entitled 
"Remote Interface Board Specification, Revision 2" ("RIB Specification"), written at least 
as early as June 21, 1996, as evidenced by the document date. A copy of the RIB 
Specification is attached as Exhibit E. The RIB Specification recites at page 3 that the RIB 
is an interface between Raptor Wire Services (the microcontroller network) and an external 
modem. The system status and commands are passed through the RS232 connection at the 
modem side to the Wire Services bus controlled through the on-board microcontroller, 
f By at least October 1996, we developed a revised version of the architecture for the 
network of microcontrollers. A document, entitled "Raptor Wire Service Architecture, 
Version 1,3" ("Wire Architecture"), was written at least as early as October 3, 1996, as 
evidenced by the document date. A copy of the cover and pages 1, 10 and 36-37 of Wire 
Architecture is attached as Exhibit F. Page 1 has a Wire Services hardware block diagram 
which shows how the remote interface connects wdth the microcontroller network so as to 
obtain system status and control various entities. Page 10 describes the event data t5^e for 
alerting extemal interfaces of events in the microcontroller network. The event data type 
were revised since the earlier version of the document. Pages 36-37 describe the Wire 
Service Remote Serial protocol used to communicate microcontroller network messages 
across a serial link firom the remote interface microcontroller attached to the server to a 
Wire Service remote management processor at the second computer. 
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g. A schematic, entitled "Schematic of P6 Mother Board, Revision 54", was written at 
least as early as October 24, 1996, as evidenced by the document date. A copy of sheet 42 
of 60 for the Speed Fan Controller section is attached as Exhibit G. This section includes 
the server end of the RJ45 connector (labeled PI 3) which interconnects the microcontroller 
network with the remote interface. The RJ45 connector also receives the independent 
power at pin 5 from the remote interface. Pin 5 of the PI 3 connector then feeds a diode 
D 15, the output of which is the Bias_5V (independent) power for the server. 

h. By at least May 1997, we developed a revised version of the architecture for the 
remote interface. A schematic, entitled "Schematic of Raptor Remote Board, Revision 50", 
was drawn at least as early as May 6, 1997, A copy of sheets 1 of 2 and 2 of 2 is attached as 
Exhibit H. 

i. By at least May 13, 1997, which is the filing date of a provisional patent application 
for the subject matter, I, Ahmad Nouri had written a document entitled "Maestro Recovery 
Manager Analysis - Problem Statement". This document was included as a portion of the 
provisional patent application filed on May 13, 1997. A copy of pages 1-3 of the document 
is attached as Exhibit 1. The Maestro Recovery Manager provides a user-fiiendly graphical 
user interface for controlling and receiving information from the microcontrollers and the 
microcontroller network. The reset operation is initiated by use of the Maestro Recovery 
Manager as described on page 3 of the document. 

5. I, Karl S. Johnson, am listed as an inventor on a provisional Patent Application No. 
60/046,397, filed May 13, 1997, which is a priority application for the subject application. I, 
Ahmad Nouri, am listed as the inventor on a provisional Patent Application No. 60/046,326, filed 
May 13, 1997, which is a priority application for the subject application. 

6. We are the listed inventors on the subject regular patent applications filed on October 1, 
1997. 

7. All acts leading to the reduction of practice were performed in the United States. 

8. This declaration is submitted prior to a final rejection. 
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Penalty of Perjury Statement 
We declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful, false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful, false statements may jeopardize the validity of the application or any 
patent resulting therefrom. 
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• Power supplies - Presence, status, A/C good, Power On/Off and Output voltages, 

• Environment - Ambient and exhaust temperatures, Fan speed, speed control, Fan fault and 
Overtemp indicators. 

• Processor - CPU Presence, Power OK, Overtemp and Fault, NMI control, System reset. 
Memory type/location and Bus/Core speed ratio. 

• I/O - I/O Canister insertion/removal and status indicator, PCI card presence, PCI card power 
and Smart I/O processor Out Of Band control. 

• Historical - Log of all system events, Character mode screen image, and Serial Numbers. 

Control of CDM functions is either intrinsic ( i.e. CDM components act automatically to perform 
the function, such as when a fan fails, the remaining fan has its speed increased and the fan 
failure indicator is lit) or external (i.e. the CDM subsystem gets external input requesting the 
function ). External functions can be initiated from either the system interface port by one of the 
P6 processors or through the RS232 serial CDM interface connected to the CDM External port. 

The CDM subsystem remote access feature provides for remote management of the system when 
the Operating System is not available^. 



2see section on Remote Management. 
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Generic Wire Service PC Message Format 

The generic Wire Service message formal is designed for easy encode/decode and reliability. It is not 
necessarily always the most compact representation possible 

Master Asserts START 



Offset 
ByteO 
Byte 1 
Byte 2 
Byte 3 
Byte 4 
Byte 5 

BytcN 



MSB 



LSB 



Slave Address 



Data Type 



R/W 



Sub- Address 



Sub-Address ( Continued ) 



Length of Data 



Data 



Checksum 



0 means PC write to slave 
R/W = 0 Mem Write / 1 Mem Read 
Most Significant Byte of Address 
Least Significant Byte of Address 
Length write or read buff sire 
Present only for memory write 



Master repeats START 
ByteO 



Byte 1 
Byte 2 

Byte N-1 
BytcN 



Slave Address (same) 



Length of Data 



Data 



Status 
Checksum 



1 means FC read from slave 
Length of Data only (N-3) 



Status 0=Succcss otherwise Failure 
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Data Type Descriptions 

Each data type description includes a rational for its existence and an example sintple protocol message. 

Bit Type 

The bit data type is to be used for simple logic valued items (TRUE/FALSE. ON/OFF, etc.) 



Read Bit Message 
Request 



Slave 
Address 


Typc/RW 


Bit Addr 
MSB 


Bit Addr 
LSB 


Request 


Check 
Byte 




Response 














Slave 
Address 


Length 
1 


Bit Value 
(0/1) 


Status 
0/Success 


Check 
Byte 




Write Bit Message 
Request 










Slave 
Address 


Typc/RW 


Bit Addr 
MSB 


Bit Addr 
LSB 


Length 
I 


Bit Value 
(0/1) 


Check 
Byte 


Response 












Slave 
Address 


Length 
6 


Status 
0/Succcss 


Check 
Byte 







Byte Type 

The byte data type is to be used for single byte valued items (0-255) 
Read Byte Message 

Request ; 



Slave 
Address 


Typc/RW 


Byte Addr 
MSB 


Byte Addr 
LSB 


Request 


Check 
Byte 


Response 




Slave 
Address 


Length 
1 


Byte Value 
(0-255) 


Status 
0/Success 


Check 
Byte 
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Write Byte Message 
Request 



Slave 
Address 


Type/RW 


Byte Addr 
MSB 


Byte Addr 
LSB 


Length 
I 


B>te Value 
(0-255) 


Check 
Byte 


Response 














Slave 
Address 


Length 
0 


Status 
O/Success 


Check 
Byte 









String Type 

The String type is designed to handle data that is best organized as variable length strings of 0 to 255 
bytes. Internal allocation of string storage for each string may be less than 255 bytes, and writing a string 
longer than available storage will return an error. 



Read String Message 
Request 



Slave 


Type/RW 


String 


String 


Request 


Check 




Address 




Addr MSB 


Addr LSB 


0-255 


Byte 




Response 














Slave 


Length 


String 




String 


Status 


Check 


Address 


N 


Data 1 




DataN 


0/Succcss 


Byte 



Write String Message 
Request 



Slave 
Address 


TypcmW 


String 
Addr MSB 


String 
Addr LSB 


Length String ... String 
N Data 0 Data N 


Check 
Byte 

Response 






Slave 
Address 


Length 
0 


Status 
0/Success 


Check 
Byte 
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The addressing of log entries has sonic special characicrisiics. 

1 ) Reading address 65565 (Oxffff) is spwaal - It represents the address of the latest entry in the log. 

2) Reading address 65564 (Oxfffc) is also special - It represents the address of the earliest available entry. 

3) The address of real log entries wraps at 655 1 9 (OxffcO. The next sequential entry after 655 1 9 is 0. 

4) The address of is ignored on write and the next available entry is written. 

5) To read the entire log in forward tinic order, read entry at address 65564. This returns the first log entry 
along with its actual log address. Inotment that address by one and read that entry. Repeat the last step 
until status indicates failure. 

6) To read the entire log in revene time order, read entry at address 65565. This returns the last log entry 
along with its actual log address. Decrement that address by one and read that entry. Repeat the last step 
until status indicates failure. 

7) To keep a complete external copy of the log. first read the entire log in forward time order and remember 
the last valid entry. Then periodically read forward from the remembered last valid entry to the end and 
add that to the external copy. 

Event Type 

The event data type is to be used for alerting external interfaces of events in the Wire Service network. 
Event mcnKwy is organized as a queue. The queue will probably be quite snull (< 20 Events). Writing an 
event places the event ID at the next available entry, unless the last queue entry would be written by this 
event In that case, the last queue entry is a Queue Overflow Event and the write fails. This allows the 
external interface to realize that events were lost and it should scan for any changes in dau. 
Reading the event type returns requested number of events in the queue or the entire queue which ever is 
less and removes them from the queue. 



Read Event Message 
Request 



Slave 
Address 


Type/RW 


N/A 


N/A 


Request 
1-255 


Check 
Byte 




Response 


Slave 
Address 


Length 
N 


Event 
IDl 




Event 
IDN 


Status ' 
0/Success 


Check 
Byte 
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Write Event Message 



Slave 


Typc/RW 


N/A 


N/A 


Length 


Event 


Check 


Address 










ID 


Byte 



Response 



Slave 


'Length 


Status 


Check 


Address 


0 


0/Succcss 


Byie 



Possible Event Types: 
CPU Status Change 
Power Sutus Change 
Canister Status Change 
Fan Status Change 



Screen Type 

The screen data type is to be used for communication of charaaer mode screen information from the 
system BIOS to remote management interface. 



Read Screen Message 
Request 



Slave 
Address 


TypcmW 


S Addr 
MSB 


S Addr 
LSB 


Request 
1-255 


Check 
Byte 






Response 


Slave 
Address 


Length 
N 


CO O 




Screen 
DataN 


Status 
0/Success 


Check 
Byte 




Write Screen Message 
Request 




SUve 
Address 


TypemW 


S Addr 
MSB 


S Addr 
LSB 


Length 
N 


Screen 
Data ! 




Screen 
Datan 


Check 
Byte 

Response 








Slave 
Address 


Length 
0 


Status 
0/Succcss 


Check 
Byte 
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Wire Service Network Memory Map 

This section defines the Wire Service Network Memory Map for the first Raptor systcnv Its purpose is to 
identify all Wire Service addressable entities and describe their function and any special information about 
them. 

This section is incomplete yet and orUy a small incomplete sample is supplied. (Although some of the 
more complicated ones are described.) 

The address format is "ppiaaaa**, where "p" is the processor ID (hexadecimal) of the Wire Service 
Processor where the data resides and "aaaa** is the hexadecimal address or address range for the data. 



Name 


Type 


Address 


Oescfiption 


Notes 


WS.DESC_Pn 


STRING 


On:0000 


Wtna Service Processor 
TypoDescripban 




WS.REV_Pn 


STRtNG 


OoOOOl 


Wire Sefvfce Software 
RevtsknMe Inf 0 




WS_SB_FAN_HI 


BfT 


03 


System Board Fans HI 


Controls S1_FAN_HI. Set on 0->1 transition of 
WS_SB.FAN.LED. Cleared by other software 


WS_SB_FAN„LED 


Brr 


03 


System Board Fan 
Faun LEO 


Controls S1_SBFAN_LED. ft is set whenew 
any WS.SB.FANFALTLTn is seL Log 0->1 
transition 


WS_S8_BUSCORE 


BYTE 


03 


System Board 
BUS^CORE speed ratio 
to use on reset 


Value is asserted on Si_BC.DS[0-3] unless 
reading DIMM types. Set too on power on. 


WS_SYS_LCD 


STRING 


03 


Vahje to tfspfay on LCD 


Fa a N]£ tfsptay the first N bytes display on 
top ine and the second N bytes dsplayonthe 
bottom line. Manipulates Sl_LCO_D(0-7J. 
SI.LCD.RS. SI.LCD.ENA. Sl.LCD.RW 


WS.SB.FANl 


BYTE 


03 


System Board Fan 1 
speed 


Approdmatety every secorxl a fan is selected by 
Sl.FAN_SEU0-2j and rtwnitorBd via 


WS.S8_FAN2 


BYTE 


03 


System Board Fan 2 
speed 


S I.FAN.TP driving a counter lor a known 
period of time. The cowter is tfwn loaded irtto 
the appropriate fan speed. If WS.SB_FAN.HI 


WS_SB.FAN3 


BYTE 


03 


System Board Fan 3 
speed 


is rK)t set then lf>e speed is compared against 
WS.SB_FAN_LOUM. H fan is stow set 
appfopriaie WS_SB_FANFAULTn otherwise 


WS.SB.FAm 


BYTE 


03 


System Board Fan 4 
speed 


dear it 


WS_SB_FANFAULT1 


BIT 


03 


System Board Fan 1 
Fautted 




WS_SB_FANFALfLT2 


BTT 


03 


System Board Fan 2 
Fautted 





Page 20 




Raptor Wire Service Architecture 



WS_SB.FANFAULT3 


BIT 


03 


System Board fm 3 
Faiitad 




WS_SB.FANFAULT4 


BfT 


03 


Sys(«m Botnl Fan 4 
Fauttad 




W S.S B.FAN.LOUM 


BYTE 


03 


Fan apaad low spaed 
laiitiimtt 


Set to 777 on power on 


W S_S B_0(MM.S EL 


BYTE 


03 


Tha DIMM salact bits to 
usa wtwi raadng 
OiMM.TYPE 


The low order 4 bits are the select bits to use 
when WS.SB_DIMM_TYPE ts read 


WS.SB„DIMM_TYPE 


BYTE 


03 


The type of DIMM in the 
DIMM_SELpos(tiai 


When rBad asserts vahie of 
WS_SB_OIMM_SEL on Sl_BC_DS[0-31 and 
then returns value of Sl_D(MM_D{0-7]- 


WS_SB.FIASH_ENA 


Brr 


04 


trvicatas FLASH ROW 
write anabted 


Set/Cloared by debounced 0->1 transition of 
S2FLASH_SW. 

Controls stated S2.FLASH.WE *kJ 
S2_FLASH_LED. 


WS.SB.FRU.FAULT 


BfT 


04 


IntScalas the FRU 
st«us 


At power on starts at 1. Contrdis 
S2_SBFLT_LE0I0-1 J for bicolor t£D c<Ars 
O-Green l-Amber. Cleared by other software 


WS.SYS.OVERTEMP 


BfT 


04 


Intfcates Owtiamp 
fautt 


At power on is set Controls 
S2_OVRTMP_LED. Contrcrftod by wire service 
bacliplane processor. 


WS_SB_JTAG 


BIT 


04 


EnaWes JTAG chain on 
system board 


dear at power on. Controis S2_SB_JTAG 


WS_SB_CPU_PRES 


BYTE 


04 


CPU Pmsence bits 
(tSB-CPUl) 


Assemble from S2_PRES_CPU11-41 


WS_SB_CPU_ERR 


BYTE 


04 


CPU Emx bits 
(LSB.CPU1) 


Asserrt)le from S2_ERROR.CPUIl-4] 


WS.SB.CPU.TEMP 


BYTE 


04 


CPU Tbemial fautt bits 
(LSB-CPU1) 


Assemble from S2_TEMP_CPUI1-4] 


WS.SB.CPU.POK 


BYTE 


04 


CPU Power OK 
(LSB.CPU1) 


Assemble from S2_P0K.CPUll^] 


WS.NMLMASK 


BYTE 


04 


CPU NMl processor 
m«sk(LSB-CPU1) 


Defautts to afl orws on power up 


WS.NMI.REO 


BfT 


04 


NMl Raquestbit 


When set pulse S2_NMI.CPUn correspcncSng 
to each bit set in WS.NMI.MASK. Thwt clear 
(eQuest biL Log Action 


WS.SYSFAULT 


BfT 


04 


System Fautt Summary 


This bit is set If anyfaults detected in the 
system. Cortrds S2_SYSFLT_LED 
Bits scanned WS_SP.CPU_FAULT, 
WS.SB.FRU.FAULT < other Iaufts7) 


WS.SB.CPU.FAULT 


err 


04 


CPU Fautt SuTTYTwy 


This bit is set B (( WS_SB_CPU_ERH 1 
WS_SB.CPU_TtMP 1 -WS.SB.CPU POK ) 
& -WS_SB.CPU_PRES) l« 0. Log 0->T 
trartsition wtth CPU bytes. 
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WS.BP.PSV 


BYTE 


02 


Analog M«asun of 4^ 
voft main supply 


rwd from S4_VOLTS.P5v 


WS.BP_P3V 


BYTE 


02 


Analog Mmsuts of 43.3 
vott main s(4)pfy 


read from S4.V0LTS_P3v 


WS_BP_P12V 


BYTE 


02 


Analog Maasurt of 4-12 
wtt main suppty 


read from S4.VOLTS.Pl2v 


WS_BP_P5V 


BYTE 


02 


Anak>gM«asurBa(*12 ' 
wtt main suppty 


read from S4_V0LTS_N12V 


WS_SYS_CAN_PRES 


BYTE 


02 


Prasanca bits for 
canisters 
(LS6«1. MSS-e) 


controOed by S4_PSN_CAN(1-€}. A previous 
wine byte needs to be maintained so carvster 
transitians can be recogniad Previous v^ue 
initialzad to zercL PeriocSc monitor scans for 
new canisters. When new canister is 
recognized read \\A serial data and store in 
WS_SYS_CAN_SERIAtji then tog and send 
went 


WS.SYS_PS_PRES 


BYTE 


02 


Prasanca bfts (or power 
suppUas 

(LSB«1.MSB»3} 


controOed by S4_PSN.PS(1-3J. A previous 
vefue byte needs to be mairlained so power 
s^PPV fransiaons can be recognized. Previous 
value initiafized to zera Periode monitor scans 
for new pomr suppBes. When rtew power 
supply b recognized read fua aerial data and 
store in WS_SYS_PS_SERIALn then log and 
send event 


WS_SYS_PS.ACOK 


BYTE 


02 


Powr supp*yACOK 
status 

(LSBs1.MSB«3) 


comn«ed by S4.ACO»ePSI1-3J. A previous 
value byte needs to be maintained so power 
supply transitions can be recognized Previous 
value initialized to zera Periocfic monitor scans 
for changes is ACOK and sends events 


WS_SYS.PS_DCOK 


BYTE 


02 


Power supp»y DCOK 
status 

(LSB«1.MSB»3) 


controOed by S4.DCOK-PS(1-3J. A previous 
^ue byte needs to be maintained so power 
st4)ply transHksns can be recognized. Previous 
value initialtzed to zera Periodic monitor scans 
for changes is ACOK and sends events 


WS_SYS_8P.TYPE 


BYTE 


02 


Type of system 
backplane currantty onty 
twotypesTypeOB4 
canister (smafT) and 
Type la 8 canister 
Oarye) 


controlted by S4_BP_TYPE 


WS.SYS.TEMP.SBI 


BYTE 


02 


TamperBtura of system 
board position 1 


controOed by ivadtf^ Oattas lamperature 
transducers connected to serial bus on 
S4_TEMP_SDA and S4.TEMP_sa. 


WS_SYS_TEMP.SB2 


BYTE 


02 


Tamper at ura of system 
board position 2 


WS_SYS_TEMP_BP1 


BYTE 


02 


TamperMureof 
bachpCane position 1 


WS_SYS_TEMP.BP2 


BYTE 


02 


Temperature of 
backplane position 2 
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WS_SYS.TEMP.WA 
RN 


BYTE 


02 


WVTVnQ 1 6fTlp6ral UTB . 

InitialtzedtoT?? 


K any WS.SYS.TEMP_jan exceeds tNs value, 
loo. send evwt. set WS.S YS.OVERTEMP 


WS.SYS.TEMP.SHU 
T 


BYTE 


02 


Wtiafiziad to 777 


H any WS.SYS.TEMP jom exceeds tNs vtf ue. 
log and dew WS.SYS.POWER 


WS.SYS_REQ_POW 
ER 


BfT 


02 


S«t to (vquest main 
f)9ft9f on 




WS_SYS_POWER 


BtT 


02 


Corttrots system master 
power 

S4_P0WER_0N 


When this bit is set 0->1 set S4 POWER.ON. 
WS_SVS.RUN - 0. WS.SYS.RSTIMER - 5 
and log. Whan tNs bit is daared dear 
S4_POWER.ONand»og. 


WS_SYS_RSnMER 


BYTE 


02 


Used to delay reset^nn 
unta power stabatzed 


Counts d(Mn to Oat 10 covtts per second. 
When 1->0 transition sets WS_SYS_RUN. 


WS_SYS_RUN 


BfT 


02 


Controts the system 

haft/nnfirte 

SI.OK-TO.RUN. 


ff this bit is deared. clear S 1_OK.TO_RUN 
and log. 

If this bit is set set Sl.OK_TO.RUN log. 


WS.CAN.POWER 


BIT 


2x 


Controls canister PCI 

StOtpOMW 


When set then set 

S5_PSV_ENAi1 „41.SS,P12V_ENA k\ that 
order with smafl (about 1 ms) delay between 
each, then log. 

When cleared then dear S5 P12V ENA, 
S5_PSV_ENAt1 then log 


WS.CAN.PCI.PRES 
ENT 


BYTE 


2x 


Reflects pa card 

s}o((1..4] presence 

irKScatorpcns 

(MSBtoLSB) 

4S.4A.3a.3A^8^1B. 

1A 


Reflects data from S5_PRSNT_Stl..4IAre] 


WS_CAN_S5_PRESE 

m 


BIT 


2x 


tndcates the presence 
something in slot 5 


Reflects SS.PRSNT.SS 


WS_CAN.S5_SMART 


BIT 


2x 


Inctcates somethtr^ 
other than a passive 
boardlnslotS 


On power tip attempt to read DaOas serial 
mimber ohip using S5.PSN_SS. tf present set 
this bit and read full serial data and store in 
WS.SYS_CAN_IOP.SERIALji 


WS.CAN.FAN.KI 


BfT 


2x 


Canistar Fans HI 


Controls S1.FAN.HI. Set on 0->1 transition of 
WS.S8.FAN_LED. Ciaarad by other software 


WS_CAN.FAN.L£0 


BTT 


2x 


Cmter Fan Fautt LED 


Controts S5.CANFAN_LE0. It is set whenever 
any WS_CAN_FANFAULTn is set Log 0->1 
transltian 


WS.CAN.FANFAULT 
1 


BIT 


03 


Canister Fan 1 Fauiled 




WS.CAN.FANFAULT 
2 


Ba 


03 


Canister Fan 2 FaUted 
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WS.CAN.FANl 


BYTE 


2x 


Canister Fan 1 spaed 


Approadmaie'y eswy second a f an is salectad t)y 
S5_FAN„SEU) and monrtored via S5.FAN.TP 
dri>^ a coulter for a known period of time. 
The counter is then loaded into the appropriate 


WS_CAN_FAN2 


BYTH 


2x 


Canister Fan 2 speed 


tan spaed. R WS.CAN.FAN.H) is not set th«i 
tt^ spaed is compared agairtst 
WS_CAN.FAN.LOUM. M f«i is slow set 
appropriate WS_QAN_FANFAULTn otherwise 
dear it 


WS.CAN FAN LOU 
M 


BYTE 


2x 


Fan low spaed fault imtt 


Set to aqutvilent of xxx RPM on power on 


WS.CAN.JTAG_Eh4A 


BTT 


2x 


Enable JTAG TMS 
chain for canister 


Copy set value to SS.CAN.JTAG 


WS_CAN_NMI.S5 


BTT 


2x 


NMI card in slot 5 


when set, pulse S2.NMLS5 


WS_RI_CO 


Bn 


11 


Status d Remote Port 
ModtfnCO 


FoOows S6_MODEM_C0 


WS^RLDTR 


BIT 


11 


State of Remote Port 
Modem DTR 


ComrtJis SC.MOOEM.OTR 


WS.RLDSR 


BIT 


11 


Status of Remote Pert 
Modem OSR 


FoBows S6.MO0EM.DSR 


WS.RI.RTS 


BIT 


11 


Status of Remote Port 
Modem RTS 


Contrds S6_MODEM_RTS 


WS.RI.CTS 


BIT 


11 


Status cf Remote Port 
Modem CTS 


Foflows SS.MODEM.CTS 


WS.RLCALLOUT 


BYTE 


11 


Controls Can out Script 
activstion 


If written to It kvtiates Call out sequence 
proorammed h WS_SYS_CAU^SCRIPT 
passing >alue as argument to script Log it 
( Format of Script Programs TBD ) 


WS.RLEVENTS 


EVENT 


11 


Remote Interf ace Event 
Queue 


See Event Data type description in pria 
section. 


WS.SI.EVENTS 


EVENT 


10 


System tmertace Event 
Queue 


See Evem Data type description in prior 
section. 


WS_SYS_LOG 


LOG 


01 


System Log 


The system log kapt in NVRAM ( See LOG 
data type in prvUous section } 


WS.SYS.SCREEN 


SCREE 
N 


01 


System Screen 


A copy cf the most recent character mode 
screen from the system video dsplay ( See 
SCREEN data type in previous section ) 


WS_SYS_SB.SERIAL 


STRING 


01 


Last known System 
Board seriat data 




WS_SYS.BP.SERiAL 


STRING 


01 


Last known Back Plant 
serial tfiU 




WS_SYS.RLSERIAL 


STRING 


01 


LASt hnown Remote 
Interiace serial data 
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WS.SYS.CAN SERI 

Aqi-ei 


STRING 


01 


Last known Canister [1- 
BlSeriddila 


May be zero length tf no canister ever seen 


WS.SYSJOP.SERIA 


STRING 


01 


Ust Icnown lOP In 
Canister [1-6] S«W 
daU 


May be zero ler^ tf no canister ever seen or 
current canister has no lOP 


WS.SLQUEUE 


QUEUE 


01 


Queue of data going to 
System Interface 


Sm Queue dMa type in previous secticn 


WS.RLQUEUE 


QUEUE 


01 


Queue cf dHA going to 
Ren>ate Interlace 


See Queue data type in previous section 


WS_SYSJ(DATA 


BYTE 
ARRAY 


01 


Byte Array for storage 
of artritrary odemol data 
in NVRAM 


Wire SerMce fust inaintatns this data area arxl 
is unaware of the meaning at any data stored in 
tt 


WS.SYS.EXT.KB 


BYTE 


01 


Size of the 

WS_SYS.XDATAIn 

loksbytes 


Necessary for memory management of the data 
area 
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EXHIBIT c 



1. Introduction: 



The purpose of this document is to describe the power on operation sequences of the 
RAPTOR system BIOS and Wire Service, The op eration sequences includes that the system at 
t he no powe r, after t he power on^ th e cold start, the wami star t, t he periph eral initialiTation^ the 
sy stem s etup, and at the TOwerjiiy vn. Two other related subjects, BIOS events code and local 
XCb display, are also included in this document. • " 

The RAPTOR Wire Service is acted as a system administrator. It monitors the signals 
which come from control switches, temperature sensors, and remote terminals. By the signals, 
the Wire Service turns on/off the power to the mother board and back plane, resets the system, 
turns the system cooling fans to high, low, or off, provide system operating parameters to BIOS, 
take the POST events information from BIOS, and sends those data to the display panel and 
remote terminals. 

The BIOS will be first called when the mother board is powered up or after reset. The 
function of the BIOS is to detect system hardware configuration, test and initialize the hardware, 
send POST events to the Wire Service, determining the operation system boot up driver, and 
provide basic input and output routines to the operation system. 

After BIOS fmished its POST task, the operation system start to boot. It checks the 
hardware configuration data from the BIOS, initializes hardware if it is necessary, installs device 
drivers, send events to the Wire Service, and response the requests for the Wire Service. 

The following block diagram shows the relationship among the system hardware, BIOS, 
Wire Service, operation system, and application software. 



Application 


BIOS 


Operation 
System 


System 


hardware 


Wire Service 
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2. System No Power 

When the system power off, there is no power to the RAPTOR mother board, back plane, 
and canisters. But, the Wire Service is still powered as system administrator,. The Wire Service 
monitors power on/off switch or the power on signal from the remote terminal. 

3. System Power On 

As the Wire Service detects that the power on/off sv^tch is on or the turn on signal from 
the remote terminal( WS_SYS_POWER is set ), it log the power on requested and temperature 
data. If the WS_SYS_OVERTEMP is set, send over temperature message to the remote terminal 
and stop. Otherwise, it set S4_P0WER_0N, set WS_SYS_RSTIMER to 5, and tum on the 
power and cooling fan on the mother board, back plane, and canisters. 

When the mother board is powered up, the BIOS POST routine is called. The BIOS first 
initialize the PCI-ISA bridge and Wire Service driver. Then, it check cold/warm start flag. If the 
system is reset by keyboard, the Warmstart procedure is called. Otherwise, the Coldstart 
procedure is called. 

The Wire Service will monitor the hardware temperature, switches on the switch control 
panel, signals from the remote terminal. It also log the BIOS POST events. 

The figure 3.1 on next page is the flow chart of the POST procedure. 



4. BIOS POST Coldstart 

In the Coldstart POST path, about sixty one (61) BIOS subroutines are called. The 
procedure of the Coldstart is grouped into following steps: 

4.1 CUP Initialization - The POST verify real mode. If the CPU is in protected mode, 
tum on the address line A20 and pulse the reset line to reset CPU. If CPU is in real 
mode, get the CPU type and save it in NVRAM. 

4.2 DMA\Timer Reset - The POST reset the DMA controllers, disable the video, clear 
any pending interrupts from the real-time clock, initialize timers, and set segment- 
register addressibility to 4GB. 

4.3 BIO Image Check - The POST verify the ROM BIOS checksums, test 512K base 
address lines, RAM, and DRAM refresh. 
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Power On /Hard Reset 

__j 



Core Logic Initialization 



Coldstart 



CUP Initialization 



DMA\Timer Reset 



BIO Image Check 



Chipset 
Initialization 



Set CPU Registers 



CMOS Test 



PCI Initialization 



Extended Memory 
Check 



Cache Enable 



Message Display 



Warmstart 



Reset Flag 



DMA\Tuner Reset 



Chipset 
Initialization 



CMOS Test 



PCI Initialization 



Cache Enable 



Message Display 



Peripheral Initialization 



I 

OS Boot Up 
Figure 3.1 the flow chart of the POST procedxire 
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4.4 Chipset Initialization - The POST initialize chip set registers, alternate registers, and 
caches registers to their initial POST values, initialize external cache, autosize 
DRAM and cache, clear 512K base RAM, shadow system BIO ROM, and set in- 
POST flag in NVRAM that indicates the BIOS is in POST, 

4.5 Set CPU Registers - The POST initialize CPU registers, enable the CPU cache, 
initialize keyboard controller, and compute CPU speed. 

4.6 CMOS Test - The POST test CMOS RAM, initialize interrupt vectors 0 through 77h 
to the BIOS general interrupt handler and DMA controller. 

4.7 PCI Initialization - The POST initialize manager for PCI option ROMs, initialize PCI 
bus and devices, check video configuration against CMOS, initialize all video 
adapters on system, shadow video BIOS ROM, test the keyboard, and test for 
unexpected interrupts. 

4.8 Extended Memory Check - In this step The POST will size and test system and 
extended memory. The POST first disable CPU cache. It, then, test RAM between 
512K and 640K, determine and test the amoimt of extended memory available, and 
perform an address lines test on AO to the amount of memory available. 

4.9 Cache Enable - The POST set cache registers to their CMOS values and enable 
external cache and CPU cache. 

4.10 Message Display - This is the last step of the cold start path. The POST display 
external cache size, shadow messages, non-disposable segments, and error messages 
if there is error. After that. The POST test the real-time clock, initialize hardware 
interrupt vectors, and reset segment-register addressibility from 4 GB to normal 64K. 
Then, the Coldstart path go to the peripheral initialization of the POST. 



5. BIOS POST Warmstart 

For the Warmstart, the system infomiaiion are already in the NVRAM. It will skip some 
POST subroutines such as verify real mode and get CPU type. In the Warmstart path, about forty 
one (41) subroutine are called, they are grouped to following steps: 

5.1 Reset Flag - The POST first clear in-POST flag in NVRAM. 

5.2 DMA\Timer Reset - The POST, then, reset the DMA controllers, disable the video, 
clear any pending interrupts from the real-time clock, initialize timers, and set 
segment-register addressibility to 4GB. 

5.3 Chipset Initialization - The POST initialize chip set registers, alternate registers, and 
caches registers to their initial POST values, initialize external cache, autosize 
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.DRAM and cache, clear 512K base RAM, shadow system BIO ROM, enable CPU 
cache, and set in-POST flag in NVRAM that indicates the BIOS is in POST. 

5.4 CMOS Test - The POST initialize DMA controller, test CMOS RAM, and initialize 
interrupt vectors 0 through 77h to the BIOS general interrupt handler, 

5.5 PCI Initialization - The POST mitialize manager for PCI option ROMs, initialize PCI 
bus and devices, check video configuration against CMOS, initialize all video 
adapters on system, shadow video BIOS ROM, reset and test the keyboard, and test 
for unexpected interrupts. 

5.6 Cache Enable - The POST set cache registers to their CMOS values and enable 
external cache and CPU cache. 

5.7 Message Display - At the last step of the warm start path. The POST display error 
messages if there is error, initialize hardware interrupt vectors, and reset segment- 
register addressibility from 4 GB to normal 64K. Then, the Coldstart path go to the 
peripheral initialization of the POST. 

6. Peripheral Initialization 

The conclusion of the POST is the point that Coldstart path and Warmstart path are 
merged together. The POST will initialize serial/parallel ports, hard/floppy disk drivers, and 
prepare boot from operation system (OS). 

6. 1 Port Initialization - The POST first disable address line A20 and onboard COM and 
LPT ports before testing for presence of external I/O devices. It, then, configure all 
PnP ISA devices, test and identify RS232 and parallel ports, and re-initialize onboard 
I/O ports. 

6.2 Controllers Initialization - The POST initialize time-outs, key buffer, soft reset flag, 
floppy and hard disk controllers, mouse, and extended BIOS data area. Then, it setup 
interrupt vector and present bit in equipment byte, install CD ROM for boot if it is 
present, and build the MPTABLE for multiprocessor. 

6.3 OS Boot Preparation - Before the system boot form OS, The POST enable hardware 
interrupts, verify that the system clock is interrupting, check the key lock, get system 
operating parameters from the Wire Service, call SETUP subroutine, store system 
operating parameters to the Wire Service, clear in-POST flag, clear the screen if BCP 
option is enable, check the total number of fast disks (ATA and SCSI), and update 
the bdaPdiskCount. 

Now the BIOS is ready to call INT 19 to boot from operation system. 
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Overview: 

This board is an interface between Raptor Wire Services and an external modem. The 
system status and commands are passed through the RS232 connection at the modem 
side to the Wire Sen/ices bus, the I2C bus. controlled through an on board PIC16C65. 
The I2C signals are translated by the PIC16C65 into an eight signal RS232 protocol and 
passed through a voltage level translator LT1 133A. with baud capable of reaching the 
speed of 120k. A 25 pin D-Sub connector resides on the other side of the voltage level 
translator. 

The system status storage is through a 32Kx8 SRAM, with an external lath for latching 
the higher addressing bits of the data RAM. A signal powered EPROM is used for 
storing board ID information. 

The board is powered through 7.5V and 700mA supply unit, and is an alternative source 
for the bias powered partition of the Wire Services. The bias powered block includes an 
NV-RAM and a PIC16C65 which are resident on the Raptor back plane. The power 
source is regulated through a high frequency switching regulator. 



1.0 Features 

The designed features are as follows: 

1.1 I2C Interface 

The two wires interface is brought from the Raptor and passed to the PIC16C65 using 
an RJ45. A bus extender 82B715 is connected between the external interface to the 
local I2C bus. Port C bit 3 is the clocking bit. and Port C bit 4 is the data line. 



1.2 RS232 Protocol 

The communication with the modem is based on the RS232. Microcontroller PIC16C65 
is used to generate the receive and the transmit signals, where the signal levels are 
transposed to the RS232 levels by the LT1133A. The 3 transmit signals, RTS. SOUT 
and DTR are from Port A bits 2, 3 and 4, where as the 5 receive signals are from two 
ports, DCD. DSR from Port C 1.0 and SIN. CTS and Rl from Port A 5. 0, 1. 

The 25 pin RS232 pin connection is used instead a 9 pin connector, since this type of 
connector is more common than the other. All the extra pins are no connect except the 
pins 1 and 7, where pin 1 is chassis ground and pin 7 is a signal ground. 
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The connection through LT1133A can be run up to 120k Baud and is ESD protected to 
+/-10kV. 

The short voltage at the output can be +/- 30V and is isolated to the forward direction 
only. 



1.3 PIC16C65and32Kx8 

A 32Kx8 SRAM is available for storage and transfer between the internal Wire Services 
and the external remote interface. Port D is the address port, while an external 
74ABT374 is for expanding the address range to 15 bits. Port B is the data bus for the 
bi-directional data interconnect. Port E is for the SRAM enable, output tristate and the 
write control signals. 

The PIC16C65 is designed for a frequency of 12MHz. An LED is also connected to the 
Port C bit 5. 







RJ45 





'^T'soOmA 



I2C Extender 







Transceiver 






4 





Figure 1: Remote Interface Interconnect 
1,4 Serial ID EPROM 

DS2502 is for storing board ID. connected to PIC16C65 Port C bit 6. The programming 
is handled through a jumper applied through connector J1. DS2502 is a signal powered, 
retaining the charge into a capacitor, sourced through the data line. 



2.1 Alternative Power Source 

The board is powered through 7.5V and 700mA (or 800mA which ever available) supply 
unit. After regulating the supply, it is an alternative source for the bias powered partition 
of the Raptor Wire Services. The bias powered block includes an NV-RAM and a 
PIC16C65 which are resident on the Raptor back plane. 

The power source is regulated through a high frequency switching regulator based on 
Linear Technology LT1376. The input to the regulator circuitry is off a wail mounted 
adapter. The regulated output is consumed locally and 300mA are sourced to the 
Raptor Wire Services through a fuse and an RJ45 P1. 

2.2 Power Consumption 

The following is an average estimated power consumption with the board running at a 
base frequency of 12MHz. 



PIC16C65 


Microcontroller 


30mA 


82B715 


I2C Extender 


10mA 


32Kx8 


SRAM 


80mA 


LT1133A 


Transceiver 


70mA 


374 


Latch 


30mA 



Misc. 



60mA 



280mA 



Alt. Source 



300mA 
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580mA 

LT1 376, LI . D2, D3. etc. 1 .45 Watts max. 



2.900 





Figure 2: Mechanical Orientation 
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2.3 Board Layout 

The board is based on controlled impedance of 60 Ohms +/- 10%, with 6 layers and test 
points for all signals. The width is restricted by the dimension of the RS232 due to the 
mounting constrains. The board is dual sided with active components kept on the top 
side only. 

The high frequency bypass is kept with .1uf and .001 uf. where the charge storage is 
kept by two 33uf and two luf capacitors. 

The location and mounting of the power connector and the LED are kept such that the 
both sides of the cabinet are identical, therefore interchangeable. 



3: Enclosure 

The enclosure is planned to be Injection Molded Aluminum, a side view is in figure 3. 
Aluminum instead of plastic is selected due to the regulator heat, and EMI shielding. 

The board connects at three locations between the top and the bottom enclosures. Two 
locations are based on the clamp shell design at the D-Sub and the RJ45. two opposite 
ends of the enclosure. The third location is a mounting hole in the center of the 
enclosure. 
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Figure 3: Board and Enclosure Isometric View 
4.0 Environment 

The environmental specification is based on assumptions: 

The environment is Ground Fixed. 
The "Quality Level of 11" is used. 

Bellcore Method I, Parts Count Method, Case 2 for prediction. 
Burn-in time 120 hours. 

Operated at 40C and 50% rated electrical stress. 
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Environmental Specification: 

MEAN TIME BETWEEN FAILURE 

2.445250e+06 Hours 

This number is calculated based on the Bellcore Technical Reference 
TR-NWT-000332, Reliability Prediction Procedure for Electronic 
Equipment, Issue 4, September 1992. 



ALTITUDE 
Operating -1 00 to 1 0,000 feet 
Non-Operating -100 to 40,000 feet 



HUMIDITY 

Operating 10% to 80% R.H., Maximum Gradient 10% per hour 

Non-Operating 5% to 90% R.H., Maximum Gradient 10% per hour 

TEMPERATURE (ambient) 

Operating 1 0 to 40 degrees C Maximum 
Gradient 10 degrees C per hour 

Non-Operating -40 to 70 degrees C 

Maximum Gradient 10 degrees C per hour 

SHOCK 

Operating 

Magnitude 2 G's (peak) 

Duration 1 1 ms . -. 

Waveform Half Sine 

Non-Operating 

Magnitude 10 . G's (peak) 
Duration 1 1 ms 
Waveform Half Sine 



VIBRATION 

Operating 

Frequency Range 

Magnitude 

Acceleration 

Non-Operating 

Frequency Range 

Magnitude 

Acceleration 



5 to 500 Hz 

0.010 inch peak to peak displacement 
0.20 GOs peak 

5 to 500 Hz 

0.010 inch peak to peak displacement 
0.50 GOs peak 
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DROP (PACKAGED) 

ASTM D4169 



ELECTRICAL 

Nominal Line 



1 1 5 VAC or 230 VAC @ 50/60 Hz autoranging 



Line Deviation 



90-130 VAC & 180-256 VAC @ 47-63 Hz 



Line Transient/Surge Susceptibility ' 1 .25 x highest rated nominal 

voltage or 300 Vrms, 
vk^hichever is less, for 1 second. 

ELECTRO-MAGNETIC COMPATIBILITY 

FCC. Class A under FCC Rule 15, Subpart B, conducted and radiated. 

Canadian Radio Interference Regulations. C.R.C., c.1374. Sec. 2. as 
amended in The Canadian Gazette, Part II. Vol. 122, No. 20, dated Sept. 
28, 1988. 

European EMC Directive (89/336/EEC) CISPR 22 (Class B). 
lEC 801-2:1984 8 kV air discharge 
lEC 801-3:1984 3 V/m, 27-500 MHz 
lEC 801-4:1988 1 kV mains, 500 V other. 



SAFETY AGENCIES 

UL, CSA. VDE, JIS 



Electrostatic Discharge 

Air Discharge 2.5 to 5.0KV no errors allowed 

5.1 to 10.0 KVrecoverable errors through system allowed 
10.0 to 20.0KV recoverable errors through 

power cycling allowed 

Contact Discharge 0 to 8.0KV recoverable errors through 



power cycling allowed 
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Raptor Wire Service Architecture 



Introduction 

"Wire Service" is the code name for the Raptor project system control, diagnostic and maintenance bus 
( formerly known as the CDM bus). Raptor is a completely "fly by wire" system - no switch, indicator 
or other control is directly connected to the function it monitors or controls. Instead, all the control and 
monitoring connections are made by the network of processors that comprise the "Wire Service" for the 
system. The processors are Microchip PIC processors and the network is a 400 kbps I^C serial bus. A 
limited understanding of I^C protocol is a prerequisite for understanding Wire Service protocols (See 
"The PC-bus and how to use it" - Philips Semiconductor, Jan 1992). Control on this bus is distributed, 
each processor can be either a master or a slave and can control resources on itself or any other 
processor on the bus. 



Wire Service Hardware Block Diagram 
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Raptor Wire Service Architecture 



Event Type 

The event data type is to be used for alerting external interfaces of events in the Wire Service network. 
Event memory is organized as a bit vector. Each bit in the vector represents a particular type of event 
and there are a minimum of 16 bits in the vector. Writing an event sets the bit representing the event in 
the bit vector. Whenever any bit in the event bit vector is non-zero, the interface indicates that events 
are present. 

Reading the event type returns one or more event ID*s, depending on request length and events actually 
pending in the interface. Once an event ID is read, the corresponding event bit is automatically cleared 
internally. 



Request 



Slave 
Address 


Type/RW 


N/A 


N/A 


Request 
1-255 




Response 




Slave 
Address 


Length 
N(I-32) 


Event 
ID 




Event 
ID 


Status 
0/Success 


Write Event Message 
Request 


Slave 
Address 


Type/RW 


N/A 


N/A 


Length 
1 


Event 
ID(1-15) 


Response 












Slave 
Address 


Length 
0 


Status 
0/Success 









Possible Event Types: 
CPU Status Change 
Power Status Change 
Canister Status Change 
Fan Status Change 
Communications Queue Event 



NetFRAMK CONFrPKNTIAL DOrTJlUFNT 

i 



Page 10 




Raptor Wire Service Architecture 



Wire Service Remote Interface Serial Protocol 

The Wire Service Remote Serial protocol is used to communicate Wire Service messages across a serial 
link from a Wire Service Remote Interface processor attached to a Raptor to a Wire Service Remote 
management processor. It encapsulates Wire Services messages in a transmission envelope to provide 
error free communications and link security. 

In order to be easily processed by the remote interface processor, the remote interface protocol is based 
on the concept of byte stuffing. That is certain hyit values in the data stream always have a particular 
meaning and if that value must be transmitted as by the underlying application as data, it must be 
transmitted as a two byte sequence. 

The bytes that have special meaning in the protocol are: 
SOM - Start of a message 
EOM - End of a message 

SUB - The following byte in the data stream must be substituted before processing 
INT - Event Interrupt 

If any of these byte values occur as data in a message, a two byte sequence must be substituted for the 
byte. That sequence is a byte with the value of SUB followed by a byte with the value of the original 
byte incremented by one. For example if a SUB byte were to occcur in a message it would appear on 
the serial data stream as a SUB followed by a byte whose value is SUB+l. 

Just as with Wire Service messages there are two classes of messages: 1) Requests - sent by remote 
managment systems (PC's) to the Wire Service remote interface and 2) Responses - returned to the 
requester by the Wire Service interface. The formats for the messages are as follows: 



Request 



1 SOM 


Seq.# 


TYPE 


Data 




Check 


EOM 


Response 


1 SOM 


Seq.# 


STATUS 


Data 




Check 


EOM 



Event Interru pt 
INT 



Where: 

SOM/EOM - Special data byte values marking the start and end of messages. 
Seq # - A one byte sequence number that increments on each request and is copied in the 
response. 
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Raptor Wire Service Architecture 



lYPE - One of the following types of requests: 

IDENTIFY- Request the remote interface to send back identification information about the 
system to which it is connected. This also resets the next expected sequence 
number. This message type does not require security authorization to be 
established first. 

SECURE - Establish secure authorization on the serial link by checking password security 
information provided in the message with the Wire Service system password. 

UNSECURE - Clear security authorization on the link and attempt to disconnect it. (Requires 
security authorization to have been established) 

MESSAGE - Take the data portion of the message and pass it to Wire Service for execution. 
The response from Wire Service is sent back in the data portion of the 
response. (Requires security authorization to have been established) 

POLL - Query the status of the remote interface. This is generally used to determine if 

an event is pending in the remote interface. 



STATUS - 
OK- 

OK EVENT 



SEQUENCE 



CHECK - 
FORMAT 

SECURE - 



One of the following response status values: 

Everything relating to communication with the remote interface was OK 
Everything relating to communication with the remote interface was OK and 
there is one or more events pending in the remote interface. 
The sequence number of the request was not the current sequence number 
(retransmission request) or the next expected sequence number (new request). 
Sequence numbers may be reset by a IDENTIFY message. 
The check byte in the request message was received incorrectly. 
Something about the format of the message was incorect. Most likley, the type 
field has an invalid value. 

The message requires that security authorization be in effect, or if the message 
was of type SECURE, the security check failed. 



Check - 



A message integrety check byte. Currently the value is 256 - the sum modulo 256 
of all previous bytes in the message, (i.e. Adding all bytes in the message up to and 
including the check byte should produce a result of zero (0) ) 



INT- 



A special one byte message sent by the remote interface when it detects the 
transistion from no events pending to one or more events pending. This message 
can be used to trigger reading events from the remote interface. Events should be 
read until the return status changes from OK_EVENT to just OK. 
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Maestro Recovery Mt^^er 
Analysis - Problem Statement 



Problem Statement 



♦ Introduction 

Maestro Recovery Manager(MRM) is a software which locally or remotely manage a Raptor 
when a server is down or up, operating system died, LAN communication failed, or other 
server components failed . 

User will be able to manage the server in very simple, usable, and friendly GUI 
environment. MRM use modem for remote and serial communication port for local to 
communicate with server for diagnostic and recovery. 

Primary role of remote management is diagnosing and restoring service as quickly as 
possible in case of a service failure. 

System administrator. LAN administrator in customer shop and NetFrame Technical support 
will be primary user for the system. 

♦ Requirement Sources 

MRM requirements comes from the following 

1 - Focus Group (Customer Support and Training .) 

2 - User Walkthrough held by MRM team and Customer Support in Dec 96 

3 - Down System Management Road map (96) 

This road map is preliminary road map combined with Up System Management 
road map. 

4 . MRM Road Map 97-98 

This Road Map presented to Engineering Council Meeting on Mar 10, 1997. 

5 - Raptor System, A Bird's Eye View. ■ 

6 - Raptor Wire Service Architecture 

The following requirements have been identified for MRM 

♦ Support Remote Management for Diagnostic and 
Recovery 

Remote Management cover remoteaccessto the Raptor Out Of Band 
management features. Remote Management will use Out of Band 
.Control Diagnostic and Monitor Subsystem (CDM) remote management to 
cover the other high value added remote management functions, primary role 
of remote management is diagnosing and restoring service as quickly as 
possible in case of service failure. 

: . 1 . 
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♦ Support Remote Management ... (continue) 

The control of Raptor is compleleiy "Fly By Wire" - i.e. no physical switch directly controls 
any function and no indicator is directly controlled by system hardware. All such functions 
referred to as "Out of Band " functions are controlled through a CDM. COM basic functions 
are available so long as A/C power is available at the input to any of the power supplies. 



CDM Subsystem supervises or monitors the following system features. 

• Power supplies - Presence, status, A/C good, Power on/off and output voltage. 

• Environment - Ambient and exhaust temperatures, Fan speed, speed control, Fan 

fault and overtemp indicators. 

• Processor - CPU Presence, Power OK, Overtemp and Fault, NMI control, 

System reset. Memory type/ location and Bus/Core speed ratio. 

• I/O - I/O canister insertion/removal and status indicator , PCI card presence, PCI 

card power and smart I/O processor Out Of Band control. 

• Historical - Log of all events, Character mode screen image, and Serial number 



♦ Support for Object Oriented Graphic User Interface 

OO-GUI is graphic user interface with the following characteristic. 

• User task oriented 

It uses tasks which user familiar and daily working with. User does not need 
to learn the tasks. 

• User objects 

It uses objects which user working with during her or his daily work. 

• Simplicity and useablity 

It is very simple to use and does not need long learning period. 

• Point and click with context sensitive help 

Context sensitive help and point and click will help user to be very 
productive and get any information he needs on specific object or field or 
subject. 

• Drag and drop 

Drag and Drop capability works with user object very well to accomplish 
the tasks. 
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♦ Release Requirements (MRM V2.0, 4Q96) 



Maestro Recovery Manager (MRM )will support the following features locally through 
serial port and Wire Service Remote Interface card on the Raptor 16. 

MRM provide user friendly GUI with point and click capability to perform the 
following tasks which reviewed and accepted by the Focus Group for 4Q96 release. 

• Power On /Off 

MRM support Power On/Off the server. 

User can do this task by right mouse click on the server object in the screen and see 
the result. 

• Display Flight Recorder. 

While the server is working . Wire Service record all the server information 
in the 64K NVRAM. After the server failed, MRM will display the system log 
recorded in the NVRAM. User can evaluate the information and find the cause for 
the server failure. This can be done by right mouse click on the Flight Recorder 
object in the screen. 

• System Reset 

MRM support rebooting the server by right mouse click on the server object in 
the screen. This is warm reboot of the server and works as pushing the 
"reset" button on the server. 

• Save 

MRM will support saving Flight Recorder data, so user can send the file 
to the technical support for further diagnostic and recovery. It also can 
save the response for any Wire Service command failure. 

• On Line help 

MRM will support online help contains overview, Getting Started, MRM 
tasks. Diagnostic and Recovery, and BIOS help. 

• BO back plane support 

MRM will support the server with BO back plane . Server with BO 
back plane display wrong time stamp. MRM uses NetWare 4. 1 1 
Operating system time stamp to display correct time stamp. 
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